Whilst traditional programming languages, such as C, C++ or Java, are very powerful and provide enormous scope to the programmer they are also complex and require extremely specialised skills. In addition complex applications require large amounts of code and often require a large team of programmers who are too far removed from the initial concepts and designs such that solutions become inefficient or different from that originally intended. As a result in some areas of software development, such as application programming, alternative techniques are evolving.
One such technique involves creating self contained pieces of software, known as components, and then scripting components together to create new components. The new component created is referred to as the parent component and its constituent components are referred to as child components. The scripting code controls execution of the parent process by controlling, for example when each child is run, where its inputs are from, where its outputs go, and what to do in the event of its failure. The basic philosophy is that, for example, business logic is written as small independent components, and applications are defined by combining these components so that they communicate in a loosely coupled manner within a managed environment. This enables application development to much more rapid since re-use for components is possible and components have clear, well defined functions.
In general, there are two key approaches to scripting together components in order to build parent components.
The first approach is to use some kind of scripting language or programming language to control the running of child components. The main advantage of this approach is that the programmer has unlimited scope to “code” when the child components are started and what actions to take with the results. The disadvantage is that this coding is still a specialized skill, each parent component must be coded by hand and the previously mentioned problems associated with existing programming with languages such as C, C++ and Java are not fully addressed.
The second approach is to provide a “builder-type” development tool that allows the application developer to draw the child components and link them together to form a graph of components. Links, for example, join the output(s) of one child component to the input(s) of another, thus specifying child component inputs, outputs and the order in which they are run. At run time an engine, known as a navigation engine, reads the graph description and runs the specified child components as specified by the graph, thus effectively automatically generating the scripting code of the first approach. Examples of this are the IBM products MQSeries Workflow and MQSeries Integrator.
“Production Workflow Concepts and Techniques” by Frank Leymann and Dieter Roller, 2000, ISBN 0-13-021753-0, discusses fully this type of “builder-type” programming and is currently considered the state of the art in this field.
An example of such a graph in a “builder-type” development tool is shown in FIG. 2 in which a parent process (201) with input port (202) and two output ports (203, 204), comprises three child components (206, 207, 208). The child components (206, 207, 208) have input ports (220, 223, 209) and output ports (221, 222, 224, 210). Arrows, such as 205, connect the output ports of one component to the input ports of others, and therefore describes the control flow. Note that processes can be nested and so a child component of a proccss can also be a process. This is shown for child component 208 which is also a process which comprises one input (209), one output (210), and four child components (211,212,213, 214). The four child components (211,212,213,214) have input ports (225, 228,230 232, 233) and output ports (226, 227, 229, 231,234). For a graph such as this, the navigation engine, on receipt of a control flow/data flow to the input 202, must: start component 206 and pass it the input flow; wait for component 206 to produce an output; end component 206; depending on which point output from component 206 is generated, start either component 207 or 208 and pass it the input flow; and so on until the graph completes.
The advantage of this type of approach is that the problem of writing and maintaining the scripting code is removed and so it is very easy to build new parent components and modify them later. The disadvantage is that the flexibility of writing the scripting code is removed and the programmer is restricted to the features of the graph and the capabilities of the associated navigation engine. As a result all possible paths through the graph need to be specified explicitly and for some problems this can lead to huge and complex graphs.
The present invention is concerned with reducing the aforementioned disadvantages of the “builder-type” environment.